Incidents were resolved by correcting mailbox objects, SMTP addresses/aliases and license state where required, and by reapplying Exchange delegation and mailbox permission entries. Administrators re‑applied Full Access for mailboxes that needed to auto‑mount in user clients or to be used by automation/service accounts, and they assigned Send‑As or Send‑on‑Behalf where sending from the shared identity was required; reapplying these permissions cleared server‑side SendAsDenied and MAPI permission failures (examples observed: HRESULT 0x80070005, EC 1244). It was observed that granting Send‑As alone (without Full Access) allowed sending from a shared mailbox in Outlook in some cases, and that granting Send‑As together with Full Access produced sent‑item copies in the shared mailbox after propagation. Temporarily assigning the shared mailbox so it appeared in Outlook sometimes enabled sending even after visibility was later removed. Public folder send permissions and distribution‑group allowed‑sender lists were adjusted when public‑folder sends produced NDRs or meeting invites were rejected. Service and automation accounts (including Power Automate flows) required Send‑As or the equivalent delegation to send as the shared identity. Client‑side changes that coincided with fixes included clearing cached From/autocomplete entries and GAL selections, restarting or recreating Outlook profiles, removing mailboxes incorrectly added as standalone accounts (which caused repeated password prompts), enabling the Outlook From control, and using manual add flows (for example Outlook “Add shared folders” or New Outlook/Outlook for Mac manual add) when auto‑mapping failed. Auto‑mapping typically completed within minutes for most recipients but occasionally failed for individual users even after multiple restarts, requiring manual add flows; permission and membership changes typically propagated in about 5–30 minutes (commonly ~10–20 minutes), though some mailboxes appeared later or the next day. Residual or orphaned permissions were removed where former members retained access. Non‑ASCII local‑parts were not accepted for SMTP addresses in some cases, so mailboxes were created with ASCII transliterations and delegation was applied to the actual SMTP address in use. Cross‑tenant boundaries prevented adding users from other Azure AD/Office 365 tenants and could not be completed by the local helpdesk. A small subset of incidents presented as intermittent client‑side send failures where messages stayed in the Outlook Outbox with no error; these had no definitive permanent fix documented and sometimes resolved spontaneously. One recorded case noted mailbox usage near quota (~40 GB of 50 GB) while the shared mailbox was missing from OWA, so mailbox size/quota was recorded as a possible contributing factor in that instance. Multiple tickets documented cases where users had Send‑on‑Behalf permission but were unable to compose and send a new message from the shared mailbox while replies from the same mailbox succeeded; those instances had no definitive remediation recorded and were associated with cached/autocomplete symptoms in some reports.

Administrators most often restored shared‑mailbox visibility by re‑granting permissions or correcting mailbox assignments and then allowing directory/permission propagation to complete (commonly ~5–30 minutes; some send‑as/send‑on‑behalf changes required up to 24 hours). Client‑side re‑synchronization typically followed a full restart or force‑close of Outlook; when auto‑mapping failed, removing and re‑adding the shared‑mailbox assignment or re‑adding the user’s primary account returned visibility. Removing a shared mailbox that had been (mistakenly) added as a separate credentialed account resolved outgoing mail and Outbox send failures in several incidents. On macOS some Outlook builds required manual addition via Delegates → Advanced or File → Open → Shared Mailbox. New Outlook desktop and Mac builds often did not auto‑map shared mailboxes, sometimes placed them under the 'Shared with me' view, and lacked pinning in affected builds. OWA generally reflected server‑side permissions and folder state immediately and was used to validate server visibility while desktop/Mac clients were stuck; OWA sometimes showed folders while client category/label metadata did not, indicating client‑side metadata/display inconsistency. Storage‑alert and large‑folder clearing events were correlated with subsequent folder sync failures where a folder appeared empty or missing; in several re‑add attempts transient authentication errors occurred but later retries succeeded. Desktop search results that showed a greyed storage location while no folder path was visible were observed in multiple cases. Favorites disappearing on every Outlook restart and the appearance of a 'Synchronization problems' folder were recorded after device migrations and often indicated local OST/profile corruption or irregular client sync behavior. Investigations confirmed that shared mailboxes were cached inside the user’s primary OST (no separate OST file), and teams inspected OST presence and size when troubleshooting. Folders visible only in Safe Mode commonly indicated add‑in conflicts; unhiding folders and restarting restored visibility in those incidents. Primary‑account authentication problems (for example, missing Microsoft Authenticator registration or SSO identity issues) produced repeated credential prompts and blocked shared‑mailbox access until the primary authentication issue was resolved. Deleted folders from a shared mailbox sometimes landed in the deleter’s personal Deleted Items rather than the shared mailbox’s Deleted Items, so recoveries required checking users’ personal Deleted Items. Deactivated mailboxes were removed from profiles after restart. During role/approver transfers, support removed old assignments and allowed reassignment propagation before auto‑mounting resumed. When administrators removed shared mailboxes but stale entries remained visible in clients, users closed/removed the mailbox from the client. Persistent cases that matched server‑side validation in OWA were classified as Microsoft‑side service or client issues and were escalated; broader mailbox service outages were resolved when the outage cleared.

Support validated mailbox identity, mailbox type (shared/service), tenant ownership, and mailbox‑level permissions and restored integrations by ensuring an interactive, appropriately entitled identity existed for the service, connector, or mailbox owner. Where integrations required an interactive login or a licensed identity, shared or non‑standalone mailboxes were converted to licensed user mailboxes or a licensed service account was assigned as the connector/approver identity; credentials were delivered via SAFE when applicable. Connector authentication failures (IMAP/OAuth token errors such as "Could not select:" or failing token flows) were resolved by refreshing or reconfiguring OAuth2 tokens and connector credentials or by switching the connector identity from a shared mailbox to a licensed service account. For SSO and third‑party flows blocked by invitation/sender‑identity mismatches, the signed‑in account was aligned with the invited/sender address. Verification codes and external file links delivered to shared mailboxes were accessed through mailbox managers or users with full‑access in Outlook, or by signing into the file host (OneDrive/SharePoint) with an interactive account. Support observed that OneDrive/SharePoint sharing to a shared mailbox was sometimes blocked with messages such as "the share must not be granted for this user," and treated this as a platform limitation; affected workflows were restored by using a licensed sender account or mailbox manager account to receive or host the shared content, or by converting the mailbox to a licensed user where appropriate. Automation approval failures (Power Automate / PowerApps) were resolved by providing a licensed interactive account (either by converting the mailbox or by assigning a licensed service account) because approvals required a licensed identity. Send‑As and Send‑On‑Behalf failures were resolved by granting required permissions to a licensed user or service account or by switching the connector identity; some third‑party apps additionally required adding the sending account to application‑level allowlists. Booking and calendar integrations that required a password (for example Calendly) were treated as incompatible with non‑interactive shared mailboxes; remedies included converting the mailbox to a licensed account, assigning a licensed service account, or consolidating notifications onto a central licensed service/no‑reply mailbox with send‑as/full‑access and reassigned calendar identities. Copilot for M365, Power Automate and Outlook connector requirements were satisfied by assigning required licenses to a service or regular user account while using the shared mailbox address as a display sender where supported. Licensing shortfalls were remedied by procuring and charging licenses to the appropriate cost center when required. Requests to create shared/community mailboxes for external agencies were refused and explained when per‑user licensing, Okta provisioning, or external domain account requirements applied; where owners required an account in a second identity system an external account was created and mailbox access granted. Administrative restrictions that prevented assigning mailbox manager roles were worked around by assigning equivalent full‑access or service‑account access. A documented product limitation was recorded for Word mail‑merge: Word used the primary Outlook account as the sender and did not honor a shared mailbox From address; similar mail‑merge scenarios were handled by using a licensed sender identity or converting the mailbox to a licensed user account.

Support removed, disabled, or corrected problematic automatic replies that were blocking, duplicating, sending outdated information, or participating in reply loops, and updated autoreply subject lines and bodies to remove retired addresses and add current contact targets. For outbound messages from SMTP/application accounts, support inspected recipient lists, identified included mailboxes with active autoreplies, and coordinated remediation such as disabling or correcting the responding mailbox’s autoreply or removing the address from system mailings. When looping or duplicate replies occurred, technicians allowed long‑unused shared mailboxes to fully synchronize (which sometimes required extended time), toggled autoresponders off to stop loops, then re‑enabled them after sync and confirmed the loop had stopped. Admins created or updated persistent (always‑on) and scheduled automatic replies for shared mailboxes and clarified permission gaps: when delegates lacked send‑as/send‑on‑behalf rights support either granted appropriate rights or configured the mailbox autoreply on behalf of the team. Support inspected mailbox forwarding rules and external targets, corrected or re‑pointed unexpected forwards, and configured forwarding from retiring addresses to active mailboxes to prevent lost mail and NDRs; deleted or retired forward targets explained some NDR cases. Ownerless or long‑unused mailboxes were identified and options were offered (assign ownership, forward to an active mailbox, or delete). Support confirmed outbound automatic replies were produced after changes and noted the Outlook UI could show an Out‑of‑Office indicator before outbound replies appeared; propagation delays of up to 24 hours were observed for newly provisioned or changed shared mailboxes. Support provided guidance and step‑by‑step assistance for enabling scheduled Out‑of‑Office on shared mailboxes (including cases where requesters lacked local permissions), recorded instructions for editing persistent automatic replies in Outlook Web (Open another mailbox → Settings → Automatic replies), and documented how to add/access shared mailboxes in Outlook mobile (noting the native iPhone Mail app does not support shared mailboxes). Support also clarified the difference between built‑in Out‑of‑Office and rule‑based auto‑replies: the built‑in Out‑of‑Office sends a single automated reply per sender per mailbox (until reset), whereas rule‑based replies apply per message or per defined criteria and can behave differently; this distinction guided whether a scheduled OOO or a rule‑based responder was recommended. Autoresponder messages were localized and reformatted where needed, subject lines and bodies were clarified (including references to known MyCampus errors), and affected shared and service mailboxes resumed normal receipt and forwarding behavior after the above actions.

The behavior was traced to the new Outlook storing signatures per user account rather than per mailbox, so messages sent from a shared/delegated mailbox defaulted to the signing user's signature and could be overwritten by other users. Resolution involved removing the full-access delegation and provisioning direct account access to the delegated mailbox: support created a temporary password, the user signed into the delegated mailbox in the Outlook web client and immediately changed the password, and the mailbox was added and used as a separate account rather than only via full-access delegation. This allowed a distinct signature to be configured for the delegated address and resolved the incorrect/unstable signature assignment.

Support inspected mailbox and folder sizes using Exchange PowerShell (Get-MailboxFolderStatistics) and identified oversized folders and archive mailboxes as the root cause of recurring quota/"archive full" warnings. Remediation actions that resolved issues included manual and bulk mailbox cleanup (including creating OWA rules to delete messages by date range) and archive management. In‑Place Archive was enabled and retention policies were applied to move older items into the archive; this provisioned a visible archive in Outlook and relieved storage pressure. Where cleanup alone was insufficient, a Microsoft 365 license was assigned to a shared mailbox to increase its quota (examples observed: 50 GB -> 99 GB / moving toward 100 GB), and Outlook was restarted to refresh the updated quota. Delegated access and third‑party forwarding integrations were reviewed when investigating unusually rapid folder growth. In a ticketing integration case, support confirmed that Freshdesk/Freshworks stored incoming emails and tickets on their cloud servers; the mailbox was inspected (most recent message dated 2024-06-11) and it was determined that active tickets were retained in Freshdesk, so deleting historical items from the Exchange mailbox did not remove tickets from the third‑party system. After these measures mail delivery issues and user-facing quota/archiving warnings were resolved.

Incidents were resolved by ensuring mailbox-level settings existed on the shared mailbox (rather than client-only entries in a user mailbox) and by identifying any clients or automations acting on the mailbox with delegated access. Shared-mailbox inbox rules and automatic replies were recreated or edited while the shared mailbox was opened in Outlook Web App (for example using Open another mailbox) so rules/replies were stored server-side and ran independently of local Outlook clients; this also removed desktop-rule failures such as 'Folder not found' when targeting folders outside a user's mailbox scope. When messages were disappearing or categories were changing, administrators reviewed mailbox audit logs and message trace results, identified the account or process performing the deletions (including Outlook clients running with Full Access or third-party connectors), removed or reconfigured the offending client/automation, and recovered items from the shared mailbox Recoverable Items folder. Where forwarding was expected but not occurring or had been applied to a user's personal mailbox, administrators verified ForwardingSmtpAddress and other forwarding properties with Exchange PowerShell (Get-Mailbox), corrected mailbox-level forwarding, and used Exchange PowerShell when EAC/ECP permissions were insufficient. Permission grants (Full Access/owner) were confirmed and typically propagated in ~15–20 minutes; affected Outlook desktop profiles became manageable after the client was restarted. For mailbox quota/cleanup scenarios or when OWA only supported fixed-date deletions, mailbox storage management or server-side cleanup tools were used to remove old messages. An administrative UI limitation was noted where limiting automatic replies on a shared mailbox to external-only senders did not always appear; requesters were informed of that constraint. Incidents consistently traced back to rules/forwarding created in the wrong scope or to a client/automation operating with delegated access that performed deletions or metadata changes.

The problem was resolved by closing Outlook, renaming the local Olk cache folder (%localappdata%\Microsoft\Olk to Olkold) to remove the corrupted cache, and restarting Outlook; normal attachment and send behavior when using the other mailbox returned afterward.

Missing older items in Exchange Online shared mailboxes were traced to Outlook desktop cached exchange behavior and to how the client exposed cached-download controls. In affected clients technicians increased the account "Mail to keep offline" (for example from 12 months to All), after which Outlook synchronized and previously inaccessible older items became visible. Where the desktop client did not expose or apply a per-mailbox cached-download setting, technicians used Outlook Web App to access the full server items; switching users to the New Outlook desktop client also restored access in some cases. Technicians noted that the folder-level prompt about additional items on the server was sometimes absent for shared mailboxes; resolving the cached-download limit or using OWA/New Outlook returned the missing items. It was documented that the offline-retention setting was a per-user setting that applied to the entire local Outlook data file, so each colleague had to change it on their own PC, and that increasing offline retention could negatively affect Outlook performance on some machines.

Investigators verified and, when required, updated the Exchange/Office 365 mailbox or mail-contact directory object; after directory replication (which sometimes took up to ~48 hours) Outlook resolved recipients with the corrected display name. Users who continued to see the old name had stale autocomplete/cached recipient entries removed from their Outlook client, which restored the updated display name. When server-side Exchange settings already matched the expected name and the issue could not be reproduced, investigators determined the observed incorrect name had been coming from automatic-reply/header content or was a transient client-side observation and closed the investigation when reporters did not provide further evidence or reproduction steps. Where different sending systems produced different sender names, investigators found third-party systems (for example Salesforce, Care, Freshdesk/ticketing apps) often set the outbound display name independently; support could not change those application settings in production, so investigators identified the mailbox/application owner and advised raising a change request or user-story with the application team to standardize the outbound display name. For replaced or newly-created shared mailboxes used for forwarding to third-party services, the mailbox was created and assigned the intended SMTP address and a forwarding-capable email address so forwarding worked as expected.

Shared, service, and functional mailboxes were provisioned and permissioned as complete mailbox objects to meet collaboration, calendaring, regulatory, and automation needs, and documented handoffs were delivered to requesters. IT created or renamed shared, licensed/service, or functional mailboxes and, when requested, added SMTP aliases or preserved legacy addresses via aliases or forwarding during agreed transition windows. Mailbox managers/owners were assigned and recorded and IT verified and communicated mailbox ownership/recipient configuration to requesters when ownership was unclear. Requested delegates were granted Full Access and Send‑As where applied (Send‑On‑Behalf handled separately), and shared calendars were provided as mailbox‑backed calendars with delegated calendar write access where requested. For automations, monitoring, or third‑party systems that required authenticated SMTP or per‑account credentials (Power Automate flows, N8N, ticketing/Salesforce endpoints, Datadog/alerts), IT provisioned licensed/service mailboxes in a service namespace and delivered service‑account credentials; otherwise shared mailboxes were treated as delegated‑access objects without separate passwords. Integration and ticketing requests were handled by creating dedicated mailboxes (and subfolder structures with delegated access) to separate internal/system/ticket traffic from external communications, linking the mailbox to the requesting queue or forwarding endpoint when provided, and configuring mailbox/channel routing, ticket assignment, permissions, DKIM/licensing, and workflow automation as part of the integration. When incoming mail was forwarded into ticketing queues and therefore did not remain in the shared mailbox, IT adjusted routing or provided a dedicated mailbox so confirmation messages remained accessible. Provisioning stalls and silent failures were investigated and resolved when the requested SMTP address was already owned by an existing Microsoft 365 Group or a hidden Teams team; requesters were offered a new mailbox plus migration, alias, or forwarding alternatives and informed about limitations (including cases where delegated Full Access did not present an expandable Inbox view). Client visibility and tenant propagation timing were communicated: new mailboxes or Groups typically appeared in minutes–~2 hours in Outlook Web/Desktop, Outlook for Mac commonly required a manual add, some clients required restart, and Send‑As/Send‑From permission changes occasionally required up to ~24 hours to propagate; New Outlook sometimes listed shared mailboxes under “Shared with me.” Additionally, IT enabled encrypted outgoing mail for shared mailboxes and configured encryption capability for specified delegates when requested. Typical deliverables included the created mailbox (shared, licensed, or service), requested SMTP/domain aliases, delegated permissions (Full Access and Send‑As where applied), configured forwarding or ticketing integration endpoints when completed, preserved content/permissions for renamed/deleted addresses where requested, assignment of mailbox managers for automation/service accounts, delivery of service‑account credentials when applicable, confirmation of mailbox ownership/recipient lists to requesters, and guidance to requesters on delegate workflows, calendaring access, naming conventions, and client visibility/propagation differences.

The failures were traced to two domain-related causes: the requested domain was not present/verified in the tenant, or the tenant enforced a restricted domain suffix requiring addresses on an approved tenant domain (for example, @iu.org). Where the tenant required an approved suffix, mailboxes were provisioned under an already-verified tenant domain (example: feedback-syntea@iu.org) and ownership and delegate access were assigned to the requested users. Where mailboxes needed to use the originally requested external domain, resolution occurred after the domain owner added and verified the domain in the Microsoft 365 tenant and published the required DNS records; mailboxes then provisioned successfully. In cases involving mailbox addresses that served as forwarding endpoints to third-party systems (for example, onlinedegree@libf.ac.uk forwarding to a Salesforce case queue), the specialist team confirmed domain availability, created the mailbox under the appropriate verified domain or the verified external domain once DNS was published, and mirrored permissions/delegation from the reference mailbox (example: learn@libf.ac.uk). Forwarding and queue endpoints were preserved by ensuring the mailbox address used by the external service existed or by re-pointing the forwarding to the newly provisioned address. After using an approved tenant domain or completing domain verification/DNS publication and aligning mailbox ownership, delegation, and forwarding targets, provisioning completed with no further error codes.

Investigators inspected the Bookings service mailbox and related distribution lists and found an email forwarding rule on the IUEmployerRelations@iu.org service mailbox that forwarded all Bookings notifications to the ex-employee's address. Removing that forwarding rule stopped the notifications. Distribution lists (employer@iu.org, s.CareerAccelerationSolutions@svc.iu-it.org) were checked and contained no forwarding to the user.

Two distinct classes of resolved delivery failures were observed, with an additional Salesforce-related investigation that remained inconclusive at the time of reporting. For AWS SES SMTP credential restrictions, delivery resumed after the SMTP user's allowed-sender list was updated to include the sending identity (no-reply@soziale-weiterbildung.de). For third-party SendGrid→Microsoft 365 deliveries that were rejected by tenant anti-spoofing despite SPF passing, delivery was restored by provisioning an externally-facing shared mailbox, granting the named users the required mailbox permissions (full access), and aligning the sending identity/domain with the mailbox and tenant anti-spoofing expectations (including domain verification and accepted-sender adjustments). Separately, several scheduled reporting jobs that had run but produced no outbound email were handled by resending the report outputs to the target inboxes (fcexams@libf.ac.uk and fccrm@libf.ac.uk), which restored delivery. A related case involved Salesforce sending via Amazon SES using unternehmen@iu.org where outbound messages intermittently failed to reach recipients and inbound messages to a shared address did not appear in Salesforce; investigators reviewed SES send logs, AWS IAM activity, and Salesforce EmailMessage records but no conclusive delivery failure or definitive remediation was recorded in that ticket.

The issue was resolved by extracting the emails that needed personal handling out of the shared mailbox and into a folder inside the user's primary mailbox. Once those messages were copied into the personal mailbox, Outlook allowed drag‑and‑drop to Tasks and the OneNote integration to operate as expected. For the recurring meeting, the support agent consolidated the selected messages into a single folder and provided them as exported message files (.mht/.html/PDF) and as forwarded attachments so they could be attached to the meeting invite or inserted into OneNote in bulk. The investigation showed the Outlook client blocked some client-side actions when the message source was a shared mailbox, and preserving the messages in the user’s own mailbox restored the expected client features.

Support determined and documented mailbox ownership, membership, and delegated permissions (including group‑based access and auto‑mapping/auto‑load behavior) and confirmed who had sign‑in or mailbox access. For broad preservation of operational correspondence support exported mailbox contents to a PST and delivered the export to stakeholders, placed the mailbox on retention hold while stakeholders confirmed long‑term needs, removed the address from active routing and the GAL, cleared sign‑in access and auto‑mapping, and scheduled final deletion per IT security retention policy after stakeholder sign‑off. When mailboxes had been disabled or lacked archives but messages were required, support confirmed archive absence and restored stakeholder access by granting delegated mailbox permissions or re‑enabling the mailbox so items could be retrieved (access was also checked via Outlook Web App). When only a small number of specific messages were required, support located the messages in the former mailbox and forwarded copies to the requester and confirmed delivery without granting full mailbox access. For continued delivery to a deprecated address support either re‑added the deprecated address as an alias on an active mailbox or configured forwarding so incoming messages arrived in an active mailbox; changes were verified by test mail and aliases/forwards were retained until references ceased. Application‑bound addresses were decommissioned by removing the address from the application’s inbound routing or configuration. Bulk consolidations of location‑specific addresses to a single central mailbox were evaluated, scheduled, and implemented with lead time for verification. When a shared mailbox was deleted, the associated auto‑mapped/pinned additional mailbox folder in users' Outlook was removed automatically, removing the need for additional local client changes in those cases. Autoresponders were configured when requested to notify senders during decommission. Ticket records captured the chosen outcome and the actions taken to address routing, alias management (GAL/routing), licensing, and the mailbox’s Azure AD lifecycle.

Support inspected the target address and directory object (distribution list/unified group, user mailbox, shared mailbox, contact/non-mailbox object, unlicensed legacy account, or no object) across Exchange/Exchange Online, Outlook and the Microsoft 365/Azure AD directory to identify the object type and routing. When a distribution list or Microsoft 365 group was the target, support reviewed membership and any sender restrictions and corrected membership entries so recipients were internal mailbox identities (removing external/personal addresses where present). Groups configured with AcceptMessagesOnlyFromSendersOrMembers were changed (for example via Set-UnifiedGroup/Set-DistributionGroup) to include the integration or service account so service notifications (such as Power BI refresh failure alerts) delivered as intended. For shared mailboxes, support noted that they appeared as separate mailboxes in Outlook and did not forward into members’ primary inboxes; colleagues or integrations were granted mailbox permissions (Full Access/Send As) or the shared mailbox was added to an appropriate group so mail could be monitored or acted on in-place. Tickets referencing misnamed or nonexistent objects were resolved by correcting the group/mailbox identity or by informing requesters that no mailbox object existed and credentials could not be issued. Legacy or unlicensed user objects were handled by confirming the directory object, licensing and any required approvals before granting access; license-group assignments were recorded where relevant. Attempts to add a distribution list or M365 group as a shared mailbox (notably observed on Outlook for Mac) produced client errors; support clarified the object type and applied the appropriate membership or permission model rather than treating non-mailbox objects as shared mailboxes. When permissions or membership were changed, support recorded that access typically appeared after a brief propagation period (about 15–20 minutes) or after restarting Outlook.

The issue was resolved by resubmitting each invoice as a separate email with a single PDF attachment and the subject line set to 'Invoice', which aligned with Capita Accounts Payable guidance v.2. After invoices were sent individually with the required subject, the AP system accepted and processed the documents.

Access issues were resolved by granting mailbox membership and/or mailbox-level permissions (full-access or delegated) and applying send-as or send-on-behalf where required; calendar permissions were granted alongside mailbox access when calendar sharing was requested. Administrators checked existing mailboxes for delegated access and forwarding settings and reviewed last-login metadata when a mailbox appeared unused. Permission changes commonly propagated within minutes (observed ~5–30 minutes; many cases used a 15–20 minute expectation for auto-mapping) and affected users regained access after propagation and client refreshes (restart or sign-out/in). When New Outlook folder-tree expansion failed or folders produced errors, reapplying proper mailbox-level permissions cleared the issue; explicit “Permission Denied” or access-denied errors in Outlook Web cleared after permissions were granted and propagation completed. Desktop Outlook or OWA’s “Open another mailbox” were used as alternate access methods when auto-mapping did not occur. Service/shared mailboxes that received external service codes were given full-access so recipients could receive those messages; because some service mailboxes did not auto-map in desktop Outlook, staff used OWA or tenant “open another mailbox” as a confirmed workaround. When requesters lacked rights to configure forwarding, administrators configured forwarding of incoming mail to specified recipients. Support routed unapproved-access requests to the Atlassian Service Desk access-request workflow (manager/CC approver) and Jira automation marked requests not approved within 14 days as declined and closed. Administrators typically added individual users (or multiple named users) to mailbox access rather than granting broad team-wide access, and mailbox-specific spam-filtering or other mitigations were applied for mailboxes receiving high volumes of spam. For persistent client-side errors (for example, folders still failed to expand and users saw messages like “folder not found” or “a client operation failed”), permissions were rechecked/reapplied and technicians offered live troubleshooting sessions (remote/Teams) to resolve remaining client or profile issues. Multiple tickets recorded confirmation that access was restored after the appropriate permissions were applied and propagation completed.

Resolution combined mailbox-forwarding fixes, sender registration in downstream ticketing APIs, remediation of upstream Microsoft mail-system changes, and manual remediation of held messages. The sender identity used by the connected system was registered as a Customer in the Jira project so API requests were accepted. Exchange forwarding behavior was changed so messages were no longer hard-forwarded without retaining a local copy; message-trace confirmed local mailbox retention and expected messages reappeared in the shared mailbox. One outage affecting OTRS delivery was traced to a recent Microsoft mail-system change; Microsoft temporarily rolled back that change and delivery to OTRS resumed. Administrators located and manually released held/blocked messages in mail queues (for example, a held message for the HEData Inbox was identified and released), which restored delivery when messages were trapped by holds or filters. As an operational mitigation during endpoint delivery interruptions, OTRS users for critical queues were granted direct access to the connected shared mailboxes and mailbox-delegation/permissions were adjusted so OTRS could access inbound messages directly when forwarding to external endpoints failed. In at least one incident a forwarding rule to a Salesforce email-to-case address had become inactive during a mailbox outage; reactivating the forwarding restored delivery to Salesforce.

The issue was resolved by accessing the shared mailbox through Outlook Web: the shared mailbox was added to the users' browser account and attachments then previewed and opened normally in OWA. 'Save to OneDrive' also remained a functional workaround when the Outlook desktop client failed. The ticket did not record changes to the Outlook desktop client itself.

Investigations identified multiple sender-identity and SMTP alignment issues. Salesforce had duplicate or unused org‑wide sender addresses and workflows that caused it to substitute a different verified shared address into the From header; outbound mail was relayed with envelope/return‑path values that did not match the tenant’s accepted SMTP identity, which produced bounces and delivery inconsistencies. Separately, Exchange configuration issues included missing or incorrect Send As/Send On Behalf permissions that produced Outlook “not authorized to send from that mailbox” errors, and a mailbox display name was set to a deactivated user which caused downstream systems to attribute tickets to that user. Remediation combined address- and tenant-level fixes: duplicate/unused org‑wide addresses were removed and the intended shared addresses were re‑verified; required departmental addresses were added/verified as org‑wide senders and made available to the correct Salesforce profiles; Salesforce’s outbound relay/envelope identity was aligned with the tenant’s accepted SMTP identity; Exchange send-as/send-on-behalf permissions and mailbox membership were corrected so Outlook could send from and display the shared mailbox address; and the mailbox display name was changed from the deactivated user to the shared mailbox name. After these changes, outbound messages preserved the expected shared From address, deliveries became reliable and visible in users’ Outlook, Salesforce compose/send-from options (including Opportunity-level Send Email) showed the required shared addresses, and downstream ticketing no longer attributed actions to the deactivated user.

A newly created shared mailbox had been granted Full Access to delegates, but Send As/Send on Behalf permissions and sent-item copy settings were missing or not yet propagated; as a result messages sent from the shared address were being saved only in the sender’s personal Sent Items. The problem was resolved by granting the appropriate send permissions (Send As and/or Send on Behalf) at the Exchange Online mailbox level and enabling the mailbox properties that preserve delegates’ copies of sent messages (MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled). After allowing time for permissions and property changes to propagate to clients, delegates were able to choose the shared From address when composing and sent messages populated the shared mailbox’s Sent Items consistently with a reference mailbox. Troubleshooting also showed the inability to change the From field was a per-user manifestation of missing or not-yet-propagated send permissions and could appear in both Outlook desktop and OWA. For recovery of specific historical sent messages and attachments, IT obtained manager-approved targeted mailbox access and searched the delegating user's Sent Items and the shared mailbox by date and recipient, recovering the message/attachment when present in either mailbox.

The root causes were residual forwarding sources outside the deleted mailbox and missing/changed mailbox forwarding permissions. Support traced and removed alternate forwarding paths (mailbox aliases, distribution lists and mailflow rules) that were still delivering mail to the ticketing system, and disabled the shared mailbox SMTP address where appropriate. For the missing notifications, an explicit copy/forward path was created under an Exchange mailflow rule or by restoring the mailbox-level forwarding/permissions so the named user received copies of incoming messages. After the extraneous forwarders were removed and the notification forwarding/permissions were restored, new messages ceased arriving at the deactivated address and the user began receiving shared-mailbox notifications as expected.

The issue was resolved by performing the deletions and a server-side purge from Outlook Web (OWA) and then forcing a client resync. Specifically, the server-side folders (including Recoverable Items) were cleared via OWA so the messages were actually removed from the server, and the Mac Outlook client was re-synced (removing and re-adding the mailbox/cache refresh) which restored correct folder counts and visibility. The root cause was a Mac Outlook client behavior where the "Empty Folder" action only cleared the local cached view and did not execute the server-side purge immediately while a 30-day deleted-item retention policy kept items on the server.

The issue was attributed to two platform behaviours. Microsoft had deprecated the supported method of opening Exchange Online shared mailboxes as standalone Outlook profiles, so creating a separate selectable profile for a shared mailbox was not possible without changing the mailbox type or assigning the appropriate licensing; cases that required licensing or mailbox-type changes were escalated to specialist teams. Separately, in the New Outlook client shared mailboxes did not appear as separate top-level accounts; they surfaced under the user's mailbox folder structure (displayed as "Shared with me" or localized equivalents such as "Für mich freigegeben"). Users who searched the mailbox folders found the shared mailbox there without needing a password or to re-add it as a separate profile.

Access issues were resolved after administrators reconciled Exchange Online mailbox permissions, mailbox manager/“report to” entries, and Microsoft 365 Group ownership so permissions were aligned across dependent systems. Remediations included granting full mailbox access and explicit management rights to allow administrative tasks (for example deleting folders), granting Send‑As or Send‑on‑behalf where required, assigning or removing mailbox manager entries, removing permissions for former employees, and reassigning group owners or obtaining mailbox access to cancel or take ownership of persistent meeting series. In several onboarding and transfer cases administrators applied the permissions of a reference/template user to new team members and performed staged rollouts to ensure parity across mailboxes and dependent systems. Support produced explicit access inventories when requested and required exact SMTP addresses to locate mailboxes or Microsoft 365 Groups. Approval-workflow failures were traced to Automation for Jira auto-declining requests after 14 days or to incorrect approver fields; those were cleared after approver entries were corrected and approvals obtained. After mailbox or group permission changes shared mailboxes typically appeared automatically in Outlook on Windows while Outlook on macOS often required manual addition; directory and mailbox synchronization times ranged from minutes to documented propagation delays of up to seven days.

Administrators confirmed the shared mailbox objects existed and restored access by re‑applying membership and mailbox permissions (Full Access and Send As/Send on Behalf when required) and ensuring the mailbox was not hidden. Re‑granting or resetting membership/Full Access repeatedly restored visibility; Windows Outlook typically auto‑mounted the mailbox within about 5–20 minutes and visibility often returned after restarting Outlook. Outlook on the web could omit the mailbox or return 'not authorized' until permissions propagated; adding the mailbox in OWA made it available once propagation completed. When automatic binding did not occur, technicians added the mailbox manually (New Outlook via Settings → Accounts → primary account → Shared mailboxes → Add shared mailbox; classic Outlook via Control Panel Mail settings; Outlook for Mac per Mac Outlook guidance). Changes to Send‑As or Send‑on‑Behalf frequently required longer propagation (commonly up to ~24 hours) before delegated sending worked. In several incidents access reappeared spontaneously without additional recorded actions. Technicians also found permissions that targeted an outdated or mismatched Azure AD account (for example after a user rename); re‑applying permissions to the correct Azure AD object immediately restored visibility. Support cases noted failures to add a mailbox with messages like 'email address not accepted', one‑user access failures while colleagues could access the same mailbox, and Outlook prompting for (and rejecting) passwords; those symptoms were associated in the ticket set with display vs. sign‑in address mismatches or credential/authentication problems (including recent password resets) and resolved after the account identity or permissions/authentication propagated and aligned.

Administrators confirmed the shared mailboxes existed and that Send‑As, Send‑On‑Behalf, or full/delegated access had been granted. Support found and resolved multiple recurring causes: shared mailboxes did not have their own passwords and therefore could not be added through Outlook’s “Add Account” flows or third‑party client account add flows; attempts to add them as separate accounts produced password prompts or credential rejections. New Outlook exposed shared mailboxes from the user’s primary mailbox in the “Für mich freigegeben” (Shared with me) area so no separate password was required. Outlook for Mac did not always auto‑provision shared mailboxes; following the manual setup guidance caused the mailbox to appear. Third‑party macOS Mail clients (Apple Mail) prompted for a password and could not be added because the shared mailbox had no password. Permission changes were observed to need propagation time (commonly ~15–20 minutes) before the shared address appeared in the From dropdown. In some cases sending failed because the compose window’s From field was hidden; enabling and then selecting the shared address allowed sending. When a user needed a shared mailbox to be added as a primary/default account (for example to run a mail‑merge), support documented that converting the shared mailbox to a user mailbox allowed it to have credentials and be added as a separate account; support also noted this approach carried risks (possible disruption to the user’s regular mailbox or unreliable effect when switching primary accounts). Mailboxes used to create tickets had incoming mail routed into Freshdesk by configuring forwarding. Support also noted that New Outlook lacked certain Classic Outlook features (for example Quick Parts / Textbaustein and ribbon customization), and users who required those features reverted to Classic Outlook.

A technician signed into the shared mailbox using OWA, confirmed the mailbox-level language setting was set to German, and re-synchronized/re-applied the Office 365 language settings for that mailbox. After the language settings were re-applied, the default folder names in the shared mailbox reverted to English.

Support investigated the shared mailbox from both Outlook desktop clients and OWA but found no actionable errors or configuration change that explained the losses. No specific remediation was performed; the user later reported the disappearance stopped spontaneously and confirmed the ticket could be closed. Prior diagnostic guidance and checks had been provided to the user but were not documented as applied, and no root cause was identified in the ticket record.